System and Method for Building and Execution of Platform-Neutral Generic Services&#39; Client Applications

ABSTRACT

A system and method of building component applications are provided. Component applications are executed on terminal devices, which communicate with a schema-based service via a network and the Internet. The component applications comprise data components, presentation components, and message components, which are written a structured definition language such as XML code. The component applications further comprise workflow components which can be written as a series of and are embedded in the XML code.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 10/745,120 filed Dec. 23, 2003 which claims thebenefit of U.S. provisional 60/1436,011, filed Dec. 26, 2002, the entiredisclosure of which is herein incorporated by reference, and furtherclaims the benefit of U.S. provisional 60/1503,665, filed Sep. 17, 2003,the entire disclosure of which is herein incorporated by reference.

BACKGROUND

This application relates generally to communication of services over anetwork to a device.

There is a continually increasing number of terminal devices in usetoday, such as mobile telephones, PDAs with wireless communicationcapabilities, personal computers, self service kiosks and two-waypagers. Software applications which run on these devices increase theirutility. For example, a mobile phone may include an application whichretrieves the weather for a range of cities, or a PDA may include anapplication that allows a user to shop for groceries. These softwareapplications take advantage of the connectivity to a network in order toprovide timely and useful services to users. However, due to therestricted resources of some devices, and the complexity of deliveringlarge amounts of data to the devices, developing software applicationsfor a variety of devices remains a difficult and time-consuming task.

Currently, devices are configured to communicate with Web Servicesthrough Internet based Browsers and/or native applications. Browsershave the advantage of being adaptable to operate on a cross-platformbasis for a variety of different devices, but have a disadvantage ofrequesting pages (screen definitions in HTML) from the Web Service,which hinders the persistence of data contained in the screens. Afurther disadvantage of Browsers is that the screens are rendered atruntime, which can be resource intensive. Native applications have theadvantage of being developed specifically for the type of deviceplatform, thereby providing a relatively optimized application programfor each runtime environment. However, native applications havedisadvantages of not being platform independent, thereby necessitatingthe development multiple versions of the same application, as well asbeing relatively large in size, thereby taxing the memory resources ofthe device. Further, application developers need experience withprogramming languages such as Java and C++ to construct these hard codednative applications. There is a need for application programs that canbe run on client devices having a wide variety of runtime environments,as well as having a reduced consumption of device resources.

The systems and methods disclosed herein provide a component basedapplication environment to obviate or mitigate at least some of theabove presented disadvantages.

SUMMARY

Current application programs are not adaptable to be run on clientshaving a wide variety of runtime environments, and can undesirablyconsume too much of device resources. Browsers are an applicationprogram that have a disadvantage of requesting pages (screen definitionsin HTML) from a Web Service, which hinders the persistence of datacontained in the screens. A further disadvantage of Browsers is that thescreens are rendered at runtime, which can be resource intensive. Nativeapplications are a further example of current application programs whichhave disadvantages of not being platform independent, therebynecessitating the development multiple versions of the same application,as well as being relatively large in size, thereby taxing the memoryresources of the device. Contrary to current application programs, asystem of building and executing platform neutral generic schema definedservices through component applications is provided. The systemcomprises component applications which execute on the devices, whichcommunicate with network service via a network such as the Internet. Thecomponent applications comprise one or more data components,presentation components, and/or message components, which are written ina structured definition language such as XML code. The componentapplications can further comprise workflow components which contain aseries of instructions such as written in a subset of ECMAScript, and,in certain implementations, can be embedded in the XML code. A method ofbuilding component applications is also provided. The method comprisessteps of creating data components, creating presentation components, andcreating message components. The data, presentation, and messagecomponents can be written in a structured definition language such asXML. The method further comprises tying together the data, presentation,and message components with workflow components written in a scriptinglanguage such as ECMAScript or a subset of ECMAScript.

A method of interacting with a schema-defined service by a terminaldevice over a network is provided herein. The method comprising sendingfrom the wireless device a request network message to the web service toestablish communication between the web service and the wireless device;receiving at the wireless device a component application in response tothe request network message, the component application programcomprising a plurality of components: a first set of the componentshaving metadata descriptors expressed in a structured definitionlanguage having a number of pre-defined elements representing specificattributes of a resource of the wireless device defining how a runtimeenvironment of the wireless device configures the component applicationprogram; and a second set of the components being expressed as a seriesof scripted instructions coupled to the metadata descriptors defining aworkflow of the component application program the workflow comprising aworkflow component for defining an action to be performed when messagesarrive at the wireless device; the components being configured forprovisioning by a runtime environment of the wireless device, theruntime environment to produce an executable version of the componentapplication program configuring the wireless device as a client of theweb service; wherein the execution of the executable version facilitatesa subsequent exchange of data over the wireless network between the webservice and the wireless device.

A wireless device configured for interacting over a wireless networkwith a web service using an executable version of a componentapplication program comprising a plurality of components is disclosed.The wireless device comprising a device infrastructure for operating thewireless device comprising a processor and an associated memory forexecuting the executable version; a user interface coupled to the deviceinfrastructure having an input device and an output device configuredfor communication with the executable version; a network connectioninterface coupled to the device infrastructure and configured forcommunicating with the network; and a runtime environment for processingthe component application program to generate the executable version forconfiguring the device as a client of the web service, the runtimeenvironment configured for processing a first set of the componentshaving metadata descriptors expressed in a structured definitionlanguage having a number of pre-defined elements representing specificattributes of a resource of the wireless device for definingconfiguration information of the component application program and asecond set of the components being expressed as a series of scriptedinstructions coupled to the metadata descriptors for defining a workflowof the component application program, the workflow component defining anaction to be performed when messages arrive at the wireless device;wherein the execution of the executable version facilitates a subsequentexchange of data over the wireless network between the web service andthe wireless device.

A computer program product for configuring a terminal device forinteracting over a network with a schema-based service using anexecutable version of a component application including a plurality ofcomponents is also provided. The computer program product comprises: acomputer readable medium; a runtime environment module stored on thecomputer readable medium for coordinating execution of the executableversion for configuring the device as a client of the service, theruntime environment configured for interaction with a first set of thecomponents having descriptors expressed in a structured definitionlanguage and a second set of the components being expressed as a seriesof instructions; wherein the execution of the executable versionprovides for a subsequent exchange of information over the networkbetween the service and the device.

In addition, a server configured for providing a schema-based servicefor interacting with a terminal device over a network is disclosed. Theserver comprises: a network interface for receiving a request networkmessage to establish communication between the service and the device; acomponent application program coupled to the network interface forsending in response to the request network message, the componentapplication program including a plurality of components, a first set ofthe components having descriptors expressed in a structured definitionlanguage and a second set of the components being expressed as a seriesof instructions, the components being configured for provisioning by aruntime environment of the device to produce an executable version ofthe component application program configuring the device as a client ofthe service; wherein execution of the executable version provides for asubsequent exchange of information over the network between the serviceand the device.

A terminal device configured for interacting over a network with aschema-based service using an executable version of a componentapplication program including a plurality of components is alsodisclosed. The device comprises; an infrastructure means for operatingthe device to execute the executable version; a user interface meanscoupled to the infrastructure means configured for communication withthe executable version; a network interface coupled to the deviceinfrastructure and configured for communicating with the network; and aruntime means for coordinating execution of the executable version forconfiguring the device as a client of the service, the runtime meansconfigured for interaction with a first set of the components havingdescriptors expressed in a structured definition language and a secondset of the components being expressed as a series of instructions;wherein the execution of the executable version provides for asubsequent exchange of information over the network between the serviceand the device.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features will become more apparent in the followingdetailed description in which reference is made to the appended drawingswherein:

FIG. 1 is a block diagram of a network system;

FIG. 2 is a block diagram of a generic terminal device of FIG. 1;

FIG. 3 is a block diagram of a component framework of the device of FIG.2;

FIG. 4 is a block diagram of a component application program of FIG. 2;

FIG. 4 a shows a representative application packaging and hosting modelfor the system of FIG. 1;

FIG. 4 b is a model of a client runtime of the device of FIG. 1;

FIG. 5 is a flowchart illustrating a method of building the wirelesscomponent application of FIG. 4;

FIG. 6 is a flowchart of a method for communicating between the deviceand a schema defined service of FIG. 1;

FIG. 7 shows an example method of implementing the component applicationprogram of FIG. 4;

FIG. 8 shows a further example method of implementing the componentapplication program of FIG. 4; and

FIG. 9 is a block diagram of a further example of the device of FIG. 1.

DESCRIPTION Network System

Referring to FIG. 1, a network system 10 comprises a plurality ofgeneric terminal devices 100 for interacting with one or more genericschema defined services provided by a network server 106, via a coupledWide Area Network (WAN) 104 such as but not limited to the Internet.These generic terminal devices 100 can be such as but not limited topersonal computers 116, wireless devices 101, PDAs, self-service kiosksand the like. The generic services provided by the server 106 can be WebServices and/or other services such as but not limited to SQL Databases,IDL-based CORBA and RMI/IIOP systems, Legacy Databases, J2EE, SAP RFCs,and COM/DCOM components. Further, the system 10 can also have a gatewayserver 112 for connecting the desktop terminals 116 via a Local AreaNetwork (LAN) 114 to the server 106. Further, the system 10 an also havea wireless network 102 for connecting the wireless devices 101 to theWAN 104. It is recognized that other devices and computers (not shown)could be connected to the web server 106 via the WAN 104 and associatednetworks other than as shown in FIG. 1. The generic terminal devices100, wireless devices 101 and personal computers 116 are hereafterreferred to as the devices 100 for the sake of simplicity. Web servicesare selected for the following description of the system 10, for thesake of simplicity. However, it is recognized that other generic schemadefined services could be substituted for the web services, if desired.Further, the networks 102, 104, 112 of the system 10 will hereafter bereferred to as the network 104, for the sake of simplicity.

Referring again to FIG. 1, the devices 100 transmit and receiverequests/response messages 105, respectively, when in communication withthe web services of the server 106. The devices 100 can operate as webclients of the web services by using the requests/response messages 105in the form of message header information and associated data content,for example requesting and receiving product pricing and availabilityfrom an on-line merchant. The web service is an example of a system withwhich client application programs 302 (see FIG. 2) on the communicationdevices 100 interact via the wireless network 104 in order to provideutility to users of the communication devices 100. The messages 105 sentbetween the communication devices 100 and the web service could traversea message-map service (not shown) which converts the messages 105between the differing formats used by the devices 100 and the webservice.

For satisfying the appropriate requests/response messages 105, the webserver 106 can communicate with an application server 110 throughvarious protocols (such as but not limited to HTTP and component API)for exposing relevant business logic (methods) to client applicationprograms 302 (see FIG. 2) once provisioned on the devices 100. Theapplication server 110 can also contain the web server 106 software,such that the web server 106 can be considered a subset of theapplication server 110. The application programs 302 of the device 100can use the business logic of the application server 110 similarly tocalling a method on an object (or a function). It is recognized that theclient application program 302 can be downloaded/uploaded in relation tothe application server 110, through the messages 105 via the network104, directly to the devices 100. It is further recognized that thedevices 100 can communicate with one or more web servers 106 andassociated application servers 110 via the networks 104. It is alsorecognized that the devices 100 could be directly coupled to theapplication servers 110, thereby bypassing the web servers 106, ifdesired.

Server Environment

Referring to FIG. 1, the web server 106 provides information messages105 which are used by the client application programs 302 (see FIG. 2)on the devices 100. Alternatively, or in addition, the web server 106may receive and use the information messages 105 provided by the clientapplication programs 302 executed on the devices 100, or perform taskson behalf of client application programs 302 executed on the devices100. The web service can be defined as a software service of the webserver 106, which can implement an interface such as expressed using WebServices Description Language (WSDL) registered in Universal DiscoveryDescription and Integration (UDDI) in a web services registry, and cancommunicate through messages 105 with client devices 100 by beingexposed over the network 104 through an appropriate protocol such as theSimple Object Access Protocol (SOAP). In some implementations, SOAP is aspecification that defines the XML format for the messages 105,including a well-formed XML fragment enclosed in SOAP elements. Otherparts of SOAP specify how to represent program data as XML and how touse SOAP to do Remote Procedure Calls (RPC). These optional parts ofSOAP are used to implement RPC-style applications where a SOAP requestmessage 105 containing a callable function, and the parameters to passto the function, is sent from the client device 100, and the server 106returns the response message 105 with the results of the executedfunction. SOAP also supports document style applications where the SOAPmessage 105 is a wrapper around an XML document. A further optional partof SOAP defines the HTTP binding (i.e. header), whereas some SOAPimplementations support MSMQ, MQ Series, SMTP, or TCP/IP transportprotocols. Alternatively, the web service may use other knowncommunication protocols, message 105 formats, and the interface may beexpressed in other web services languages than described above.

In general, web services come as a replacement for legacy Browser-basedand Client-Server TCP/IP connected infrastructure and applications.Originally started as a generic machine-to-machine (M2M) communicationprotocol, web services are becoming a standard for anyservice-to-service (S2S) or service to consumer (S2C) communications.Based on a set of standard protocols (e.g. WSDL, SOAP, UDDI), webservices can provide a platform neutral communication pipe, for exampleXML-based, that can support synchronous and/or asynchronouscommunication messages 105. The system 10 of FIG. 1 relates preferablyto the S2C model and deals with the consumer of the web serviceoperating from some generic terminal device 100. Accordingly, theservices supplied by the server 106 are utilized by the user of thedevices 100 over the network 104.

Client Environment

Referring to FIG. 2, the component applications 302 are transmitted viathe network 104 and loaded into a memory module 210 of a deviceinfrastructure 204 of the device 100. Alternatively, the componentapplications 302 may be loaded via a serial connection, a USBconnections, or a short-range wireless communication system such as IR,802.11(x) Bluetooth™ (not shown). Once loaded onto the device 100, thecomponent applications 302 can be executed by a component framework 206on the device 100, which converts the component applications 302 intonative code, which is executed by a processor 208 in the deviceinfrastructure 204. Alternatively, the component applications 302 may beexecuted as native code or interpreted by another software module oroperating system on the device 100. In any event, the componentapplications 302 are run in a terminal runtime environment provided bythe device 100.

Referring again to FIG. 1, the client runtime environment provided bythe devices 100 can be configured to make the devices 100 operate as webclients of the web services (of the web server 106). It is recognizedthat the client runtime environment can also make the devices 100clients of any other generic schema-defined services supplied by theserver 106. The client runtime environment of the devices 100 ispreferably capable of generating, hosting and executing the clientapplication programs 302 (which are in the form of componentapplications—see FIG. 4 and description herein below) on the device 100.Further, specific functions of the client runtime environment caninclude such as but not limited to support for language, coordinatingmemory allocation, networking, management of data during I/O operations,coordinating graphics on an output device of the devices 100 andproviding access to core object oriented classes and supportingfiles/libraries. Examples of the runtime environments implemented by thedevices 100 can include such as but not limited to Common LanguageRuntime (CLR) by Microsoft and Java Runtime Environment (JRE) by SunMicrosystems.

The terminal runtime environment of the devices 100 preferably supportsthe following basic functions for the resident executable versions ofthe client application programs 302 (see FIG. 2), such as but notlimited to:

provide a communications capability to send messages 105 to the WebServices of the web server 106 or messages 105 to any other genericschema defined services connected via the network 104 to the devices100;

provide data input capabilities by the user on an input device of thedevices 100 to supply data parts for Web Services' outgoing messages 105(messages to the service) of the web server 106;

provide data presentation or output capabilities for Web Services'response messages 105 (incoming messages) or uncorrelated notificationsof the web server 106 on the output device;

provide data storage services to maintain local client data in thememory module 210 (see FIG. 2) of the device 100; and provide anexecution environment for a scripting language for coordinatingoperation of the application components 400, 402, 404, 406 (see FIG. 4)of the client application programs 302.

Referring to FIGS. 2, 4 and 4 a, the client runtime (for exampleprovided by the component framework 206) loads the metadata contained inthe component 400, 402, 404, 406 definitions and the builds theexecutable version of the application program 302 on the device 100, viaan application container 300. For example, there are two operationalmodels for client runtime: template-based native execution andmetadata-based execution. With the template-based native execution modelthe runtime hosts data, message, and screen templates 500 pre-built onthe device 100 using the native code. When the application program 302definition is loaded, the client environment provided by the componentframework 206 fills the templates 500 with metadata-defined parametersfrom the components 400, 402, 404 and builds the executable clientapplication program 302 in the native format. The workflow script (forexample ECMAScript) of the workflow component 406 could be eitherconverted to native code or executed using an appropriate scriptinterpreter 502 (e.g., ECMAScript Interpreter) to a native coderedirector 504, where the redirector 504 interprets calls to thescripting language into operations on native components through a nativeruntime engine 506. With the metadata-based execution, the runtimeenvironment of the component framework 206 either keeps component 400,402, 404, 406 definitions in XML (for example), which are parsed duringexecution time or uses native representation of XML (for example) nodes.During execution, the native runtime engine 506 operates on definitionsof the components 400, 402, 404, 406 rather than on native componententities. It is recognized that the template based approach can be moreperformance efficient over the metadata based execution, but can requirea more sophisticated execution environment and more memory resources.

Therefore, the native client terminal runtime environment provides aninterface for the client application programs 302 to the device 100functionality of the processor 208 and associated operating system ofthe device infrastructure 204. The runtime environment preferablysupplies a controlled, secure and stable environment on the device 100,in which the component application programs 302 execute. The runtimeenvironment provisions the definitions of the components 400, 402, 404,406 to create the actual web client specific for each respective deviceinfrastructure 204 of the devices 100. It is recognized for the sake ofsimplicity that the following description hereafter will refer to theclient runtime environment being provided by the component framework206, as an example only.

Communication Device

Referring to again to FIG. 2, the devices 100 are devices such as butnot limited to mobile telephones, PDAs, two-way pagers or dual-modecommunication devices (see FIG. 9). The devices 100 include a networkconnection interface 200, such as a wireless transceiver or a wirednetwork interface card or a modem, coupled via connection 218 to adevice infrastructure 204. The connection interface 200 is connectableduring operation of the devices 100 to the network 104, such as to thewireless network 102 by wireless links (e.g., RF, IR, etc.), whichenables the devices 100 to communicate with each other and with externalsystems (such as the web server 106) via the network 104 and tocoordinate the requests/response messages 105 between the clientapplication programs 302 and the servers 106, 110 (see FIG. 1). Thenetwork 104 supports the transmission of data in the requests/responsemessages 105 between devices and external systems, which are connectedto the network 104. The network 104 may also support voice communicationfor telephone calls between the devices 100 and devices which areexternal to the network 104. A wireless data transmission protocol canbe used by the wireless network 102, such as but not limited to DataTAC,GPRS or CDMA.

Referring again to FIG. 2, the devices 100 also have a user interface202, coupled to the device infrastructure 204 by connection 222, tointeract with a user (not shown). The user interface 202 includes one ormore user input devices such as but not limited to a QWERTY keyboard, akeypad, a trackwheel, a stylus, a mouse, a microphone and the useroutput device such as an LCD screen display and/or a speaker. If thescreen is touch sensitive, then the display can also be used as the userinput device as controlled by the device infrastructure 204. The userinterface 202 is employed by the user of the device 100 to coordinatethe requests/response message messages 105 over the system 10 (seeFIG. 1) as employed by client application programs 302 of a componentframework 206, further described below.

Referring again to FIG. 2, operation of the device 100 is enabled by thedevice infrastructure 204. The device infrastructure 204 includes thecomputer processor 208 and the associated memory module 210. Thecomputer processor 208 manipulates the operation of the networkinterface 200, the user interface 202 and the component framework 206 ofthe communication device 100 by executing related instructions, whichare provided by an operating system and client application programs 302located in the memory module 210. Further, it is recognized that thedevice infrastructure 204 can include a computer readable storage medium212 coupled to the processor 208 for providing instructions to theprocessor and/or to load/update client application programs 302 in thememory module 210. The computer readable medium 212 can include hardwareand/or software such as, by way of example only, magnetic disks,magnetic tape, optically readable medium such as CD/DVD ROMS, and memorycards. In each case, the computer readable medium 212 may take the formof a small disk, floppy diskette, cassette, hard disk drive, solid statememory card, or RAM provided in the memory module 210. It should benoted that the above listed example computer readable mediums 212 can beused either alone or in combination.

Component Framework of Device

Referring again to FIG. 2, the component framework 206 of the device 100is coupled to the device infrastructure 204 by the connection 220. Theclient runtime environment the device 100 is provided by the componentframework 206, and is preferably capable of generating, hosting andexecuting the client application programs 302 (which are in the form ofcomponent applications—see below) from meta-data definitions. Therefore,component framework 206 provides the native client runtime environmentfor the client application programs 302 and is an interface to thedevice 100 functionality of the processor 208 and associated operatingsystem of the device infrastructure 204. The component framework 206provides the runtime environment by preferably supplying a controlled,secure and stable environment on the device 100, in which the componentapplication programs 302 execute in an application container 300, forexample. The application container 300 can be referred to as a smarthost container for the client application program 302, and can beresponsible for analyzing message meta-data (of the messages 105—seeFIG. 1) and for updating the representation of the meta-data in thememory module 210.

Referring to FIG. 3, the component framework 206 can be used to executethe client application programs 302 (such as Web Service clientapplications) within the terminal runtime environment and can supportaccess to Web Service operations of the web servers 106 and associatedapplication servers 110 (see FIG. 1), via the request/response messages105. The component application programs 302 comprise softwareapplications which are executed by the component framework 206. Thecomponent framework 206 creates the application container 300 for eachcomponent 400, 402, 404, 406 (see FIG. 4) of the application program302, each time that the component application program 302 is executed.The application container 300 loads the components 400, 402, 404, 406 ofthe application program 302 and can create native code which is executedby the processor 208 in the device infrastructure 204. The componentframework 206 therefore provides the host application containers 300 forprovisioning the definitions of the components 400, 402, 404, 406 tocreate the actual web client specific for each respective deviceinfrastructure 204 of the communication devices 100,116. The applicationcontainer can provision the component application 302 as per thetemplate-based native execution and metadata-based execution models asdescribed above.

Referring again to FIG. 3, the component framework 206 can also provideframework services 304 (a standard set of generic services) to theclient application programs 302, in the event certain services are notincluded as part of the components 400, 402, 404, 406 (see FIG. 4) orreceived as separate components (not shown) as part of the componentapplication program 302. The application program 302 has communications214 with the application container 300, which coordinates communications216 with the framework services 304, as needed. The framework services304 of the component framework 206 coordinate communications via theconnection 220 with the device infrastructure 204. Accordingly, accessto the device infrastructure 204, user interface 202 and networkinterface 200 is provided to the client application programs 302 by thecomponent framework 206. In addition, the client application programs302 can be suitably virus-resistant, since the application containers300 can control and validate all access of the communications 214, 216of the component framework 206 to and from the client applicationprograms 302. It is recognized that a portion of the operating system ofthe device infrastructure 204 (see FIG. 2) can represent the applicationcontainer 300.

Referring again to FIG. 3, the below described components 400, 402, 404,406 (see FIG. 4) of the application program 302, once provisioned on thecommunication device 100,116 are given access to the predefined set offramework services 304 by the application containers 300 of thecomponent framework 206. The framework services 304 include such as butnot limited to a communication service 306, a presentation service 308,a persistence service 310, an access service 312, a provisioning service314 and a utility service 316. The communication service 306 managesconnectivity between the component application programs 302 and theexternal system 10, such as the messages 105 and associated datasent/received in respect to the web service (by the communicationservice 306) on behalf of the component applications 302. Thepresentation service 308 manages the representation of the componentapplication programs 302 as they are output on the output device of theuser interface 202 (see FIG. 2). The persistence service 310 allows thecomponent application programs 302 to store data in the memory module210 (see FIG. 2) of the device infrastructure 204. The access service312 provides the component application programs 302 access to othersoftware applications which are present on the communication device100,116. The provisioning service 314 manages the provisioning ofsoftware applications on the communication device 100,116. Applicationprovisioning can include requesting and receiving new and updatedcomponent application programs 302, configuring component applicationprograms 302 for access to services which are accessible via the network104, modifying the configuration of component application programs 302and services, and removing component application programs 302 andservices. The utility service 316 is used to accomplish a variety ofcommon tasks, such as performing data manipulation in the conversion ofstrings to different formats.

It is recognized that the framework services 304 of the communicationdevice 100 can provide functionality to the component applicationprograms 302, which can include the services described above. As aresult, the component application programs 302 can have access to thefunctionality of the communication device 100 without having toimplement it. The component framework 206 of the device 100 (see FIG. 2)has only preferably one copy of the code which implements these servicespresent in the framework services 304, regardless of the number ofcomponent application programs 302 which are present, thereby minimizingcode duplication of the framework services 304. Further, unlike ordinaryapplications where all service requests or service API calls areprogrammed by developers in the native code, the component definitions400, 402, 404 and workflow 406 describe service requests using astructured definition language such as XML and the set of instructionssuch as ECMAScript. The structured definition language provides anon-procedural definition of the application's user interface 202,persistent storage and communications with the Web Service, while theinstructions provide the procedural component linkage. The Clientruntime environment interprets these definitions 400, 402, 404 into thenative calls to supported services.

Component Application Program

Referring to FIG. 2, the Web Service (for example) client applicationprograms 302 are executed within the terminal runtime environment of thecomponent framework 206 and support access to Web Service operationsprovided by the server 106 (see FIG. 1). WSDL and SOAP protocoldefinitions clearly imply a messages/data pattern. In a WSDL Web Servicedefinition, the operations are defined using the notion of messages anddata parts, which are used to define the Web Service client applicationprograms 302 as a set of the related data 400 and the message 404components (see FIG. 4).

Referring to FIG. 4, a block diagram of the component applicationprogram 302 comprises the data components 400, the presentationcomponents 402 and the message components 404, which are coordinated byworkflow components 406 through communications 214 with the applicationcontainer 300. The structured definition language can be used toconstruct the components 400, 402, 404 as a series of metadata records,which consist of a number of pre-defined elements representing specificattributes of a resource such that each element can have one or morevalues. Each metadata schema typically has defined characteristics suchas but not limited to; a limited number of elements, a name of eachelement, and a meaning for each element. Example metadata schemasinclude such as but not limited to Dublin Core (DC), Anglo-AmericanCataloging Rules (AACR2), Government Information Locator Service (GILS),Encoded Archives Description (EAD), IMS Global Learning Consortium(IMS), and Australian Government Locator Service (AGLS). Encoding syntaxallows the metadata of the components 400, 402, 404 to be processed bythe device infrastructure 204 (see FIG. 2), and encoding schemes includesuch as but not limited to XML, HTML, XHTML, XSML, RDF, Machine ReadableCataloging (MARC), and Multipurpose Internet Mail Extensions (MIME).

Referring again to FIG. 4, the data components 400 define data entitieswhich are used by the component application program 302. Examples ofdata entities which data components 400 may describe are orders, users,and financial transactions. Data components 400 define what informationis required to describe the data entities, and in what format theinformation is expressed. For example, the data component 400 may definesuch as but not limited to an order which is comprised of a uniqueidentifier for the order which is formatted as a number, a list of itemswhich are formatted as strings, the time the order was created which hasa date-time format, the status of the order which is formatted as astring, and a user who placed the order which is formatted according tothe definition of another one of the data components 400. Since dataparts (elements) are usually transferred from message 105 to message 105according to Web Services choreography rules, preferably there ispersistence of data components 400. Data components 400 may bedynamically generated according to Web Service(s) choreographydefinitions (if available) or defined by the application designer basedon complex type definitions and/or message correlation information.

Referring again to FIG. 4, the message components 404 define the formatof messages used by the component application program 302 to communicatewith external systems such as the web service. For example, one of themessage components 404 may describe such as but not limited to a messagefor placing an order which includes the unique identifier for the order,the status of the order, and notes associated with the order. Messagecomponent 404 definitions written in the structured definition languagecan uniquely represent (and map to) WSDL messages, and can be generateddynamically at runtime. Accordingly, the dynamic generation can be donefor the component definitions for client application messages 105, andassociated data content, from standard Web Service metadata in thedefinition language used to express the web service interface, forexample such as but not limited to WSDL and BPEL. Web Services messages105 are defined within the context of operation and there is definedcorrelations between the message components 404 in the componentapplication program 302 definition. This correlation could be done usingpredefined message parameters and/or through separate workflowcomponents 406, as further defined below.

Referring again to FIG. 4, the presentation components 402 define theappearance and behavior of the component application program 302 as itdisplayed by the user interface 202. The presentation components 402 canspecify GUI screens and controls, and actions to be executed when theuser interacts with the component application 302 using the userinterface 202. For example, the presentation components 402 may definescreens, labels, edit boxes, buttons and menus, and actions to be takenwhen the user types in an edit box or pushes a button. The majority ofWeb Service consumers use a visual presentation of Web Service operationresults, and therefore provide the runtime environment on their devices100 capable of displaying user interface screens.

Referring to FIGS. 1, 4 and 4 b, it is recognized that in the abovedescribed client component application program 302 definitions hostingmodel, the presentation components 402 may vary depending on the clientplatform and environment of the device 100. For example, in some casesWeb Service consumers do not require a visual presentation. Theapplication definition of the components 400, 402, 404, 406 of thecomponent application program 302 can be hosted in a Web Serviceregistry in a metadata repository 700 as a bundle of platform-neutraldata 400, message 404, workflow 406 component descriptors with a set ofplatform-specific presentation component 402 descriptors for variouspredefined client runtimes (i.e. specific component frameworks 206—seeFIG. 2). When the discovery or deployment request message 105 is issuedthe client type should be specified as a part of this request message105. In order not to duplicate data, message, and workflow metadatawhile packaging component application programs 302 for different clientplatforms of the devices 100, application definitions can be hosted onthe application server 110 (for example) as a bundle of platform-neutralcomponent definitions linked with different sets of presentationcomponents 403 a, 403 b, 403 c, representing the different supporteduser interfaces 202 of the devices 100. It is also recognized that astandard presentation component 402 can be used in the event thespecific device 100 is not explicitly supported, thereby providing atleast a reduced set of presentation features. When a user makes adiscovery or download request message 105, the client runtime type ofthe devices 100 is validated and the proper bundle is constructed fordelivery by the web server 106 to the device 100 over the network 104.For those Web Service consumers, the client application programs 302could contain selected presentation components 403 a,b,c linked with thedata 400 and message 404 components through the workflow components 406,thereby providing a customized component application 302.

Referring again to FIG. 4, the workflow components 406 of the componentapplication program 302 define processing that occurs when an action isto be performed, such as an action specified by a presentation component402 as described above, or an action to be performed when messages 105(see FIG. 1) arrive from the system 10. Presentation workflow andmessage 105 processing are defined by the workflow components 406. Theworkflow components 406 are written as a series of instructions in aprogramming language or a scripting language, such as but not limited toECMAScript, and can be compiled into native code and executed by theapplication container 300, as described above. An example of theworkflow components 406 may be to assign values to data, manipulatescreens, or send the message 105. The workflow component 406 supports acorrelation between the messages 105 and defines application flow as aset of rules for operations on the other components 400, 402, 404.Multiple workflow components can be defined with respect to a givenapplication program 302. Such additional workflow components, similar tothe multiple presentation components 403 a, 403 b, 403 c, can definediffering work flows based upon different supported capabilities orfeature of particular devices 100.

ECMA (European Computer Manufacturers Association) Script is a standardscript language, wherein scripts can be referred to as a sequence ofinstructions that is interpreted or carried out by another programrather than by the computer processor. Some other example of scriptlanguages are Perl, Rexx, VBScript, JavaScript, and Tcl/Tk. Thescripting languages, in general, are instructional languages that areused to manipulate, customize, and automate the facilities of anexisting system, such as the devices 100. In such systems, usefulfunctionality is already available through the user interface 202 (seeFIG. 2), and the scripting language is a mechanism for exposing thatfunctionality to program control. In this way, the device 100 is said toprovide the host runtime environment of objects and facilities whichcompletes the capabilities of the scripting language.

Specifically, EMCAScript is an object-oriented programming language forperforming computations and manipulating computational objects withinthe host runtime environment. ECMAScript can be used as a Web scriptinglanguage, providing a mechanism to perform server 106,110 computation aspart of the Web-based client-server architecture of the system 10 (seeFIG. 1). ECMAScript provides core scripting capabilities for a varietyof host runtime environments, and therefore the core scripting languagecan be considered platform neutral for a number of particular hostruntime environments. The component framework 206 (see FIG. 2) canprovide the ECMAScript host runtime environment for client-sidecomputation of the devices 100, such as but not limited to; objects thatrepresent windows, menus, pop-ups, dialog boxes, text areas, anchors,frames, history, cookies, and input/output. Further, the host runtimeenvironment of the component framework 206 provides a means to attachscripting code to events such as but not limited to change of focus,page and image loading, unloading, error, and abort, selection, formsubmission, and mouse actions. The scripting code appears within theworkflow components 406, combines user interface elements and fixed andcomputed text and images, and is reactive to user interaction on theuser interface 202. The web server 106 (see FIG. 1) provides a differenthost environment for server-side computation including objectsrepresenting requests, clients, and files, and mechanisms to lock andshare data. By using the client side and server side scripting together,it is possible to distribute computation between the client devices 100and the servers 106,110 while providing a customized user interface 202for the Web-based component application programs 302.

ECMAScript also defines a set of built-in operators which may not be,strictly speaking, functions or methods. ECMAScript operators includesuch as but not limited to various unary operations, multiplicativeoperators, additive operators, bitwise shift operators, relationaloperators, equality operators, binary bitwise operators, binary logicaloperators, assignment operators, and the comma operator. ECMAScriptsyntax resembles Java syntax, however, ECMAScript syntax is relaxed toenable it to serve as an easy-to-use scripting language for developers.For example, a variable in ECMAScript is not required to have its typedeclared nor are types associated with properties, and defined functionsare not required to have their declarations appear textually beforecalls to them. It is recognized that in a class-based object-orientedprogramming language, in general, state is carried by instances, methodsare carried by classes, and inheritance is only of structure andbehavior. In ECMAScript, the state and methods are carried by objects,and structure, behavior, and state are all inherited.

Component Application Program Example

Accordingly, referring to FIG. 4, the client application programs 302can be defined as a set of platform-neutral component definitions,namely for data 400 and message 404 components, and presentationcomponents 402 using XML (or any other suitable structured definitionlanguage). The workflow components 406 can be defined using ECMAScript(or any other suitable platform-neutral scripting language). The clientruntime environment of the component framework 206 (see FIG. 2) cangenerate component templates based on meta-definitions, as furtherdescribed below, when the components 400, 402, 404, 406 of the componentapplication program 302 are provisioned on the device 100. With a largevariety of terminal runtime environments, the cross-platform standardssuch as XML or ECMAScript can be used to define application componentmetadata instead of pre-building the component application programs 302.This delayed binding can allow generic application definitions of thecomponent application programs 302 to be run on a wide variety ofterminal system environments, represented by various different devices100.

Expressing the data 400, message 404, and presentation 402 componentsusing XML or its derivatives, and the workflow component 406 using theECMAScript language or its subset, can allow an application developer toabstract the Web Service client from any specific platform orenvironment and implement in principle “develop once run everywhere”applications. The following example shows how a Web Services clientapplication program 302 could be expressed using a structured definitionlanguage, such as but not limited to XML, and a platform neutralscripting/programming language, such as but not limited to ECMAScript,defined components:

Example XML Data Components 400

<data name=″Order″> <item name=″orderId″ type=″Number″ key=“true”/><item name=“items″ type=″String“ array=″true″/> <item name=″user″comp=″true″ compName=″User″/> <item name=″orderStatus″ type=″String″/></data> ...

Example XML Message Components 404

<msg name=“ordConfirmation″ type=”response” action=“mhConfirmation″><part name=“orderId″ type=″String“/> <part name=“status″ type=″String“/></msg> ...

Example XML Presentation Components 402

<screen name=″scrConfirmation″ title=“Order Confirmation″ param=″Order″><layout type=″vertical″> <widget type=″label″ value=″Order ConfirmationResult:″/> < widget type=″edit″ value=″@Order.orderStatus″/> </layout>... <menu> <item label=″Continue″ navigate=″@scrMain″/> ... </menu></screen> ...

Example ECMAScript Workflow Components 406

<actions> <function name=”mhConfirmation”> key =ordConfirmation.orderId; order = Order.get(key); order.orderStatus =ordConfirmation.status; scrConfirmation.display(order); </function> ...</actions>

Referring to FIG. 4, as given above, it can be seen that the messagecomponents 404 relay the required data for the input and output of themessages 105. The corresponding data components 400 coordinate thestorage of the data in the memory module 210 (see FIG. 2) of the device100 for subsequent presentation on the user interface 202 (see FIG. 2)by the presentation components 402. The workflow components 406coordinate the transfer of data between the data 400, presentation 402,and message 404 components.

There are a number of potential advantages to the component applicationmodel as described above. For example, there is a minimized need for amediator in the service protocol between client runtime and serviceendpoint. Unlike browser-based applications that require a Web Server tohost additional components (e.g. servlets, JSP, ASP, etc.) to connectHTML pages data/requests with a service endpoint, the componentapplication model allows end-to-end direct connectivity between theclient runtime of the device 100 and the service endpoint using WebService (on the server 106) message component definitions.

Further, the component application model combines the simplicity ofbrowser-based applications with the efficiency of native applicationexecution. Unlike browser applications, rendering screens at runtime isminimized as the whole application 302 definition is downloadedpreferably at once and the client runtime environment can generate anative representation of application screens. Additionally, requestingof pages (screen definitions in HTML) from the server is minimized, asthe component application model architecture is based on messagecomponents 404 that contain data.

Further, the component application architecture can provide a relativelysmall application download size (consisting of component definitionsonly) as compared to hard coded native applications, and an effectivedata storage and persistence model. The client runtime is capable ofstoring and updating atomic data entities directly vs. manipulatingrendered presentations such as HTML pages for browser applications.

Further, the component application architecture can provide aplatform-neutral model. Unlike native applications uniquely developedfor a specific client runtime, the applications 302 built using widelyadopted standards such as XML and ECMAScript could be reused on a largevariety of platforms and truly implement the principle “write once runeverywhere”. Further, the combination of non-procedural and proceduralapplication definitions can greatly reduce programming time and effort.

Operation of Component Application Model

FIG. 5 is a flowchart illustrating a method of building the wirelesscomponent application 302 for subsequent communication over the network104 to the device 100. Referring as well to FIG. 3, the method beginswith step 600 of creating the data components 400 for defining dataentities such as users and orders. The method continues with step 602 ofcreating presentation components 402 for defining user-interfaceelements such as screens, buttons, menus and images. The methodcontinues with step 604 of creating message components 402 for definingmessages formats which are sent to external systems such as web serviceson the server 106 (see FIG. 1). The components 400, 402, 404 areexpressed in the structured definition language such as but not limitedto one based on XML. The method concludes with step 606 of tyingtogether the data 400, presentation 402 and message 404 components withworkflow components 406 in order to define the behavior of theapplication 302. The workflow components 406 are written based on ascripting language such as a subset of ECMAScript, which is describedabove. The method of building a wireless component application 302 mayinclude fewer or more steps that those shown in FIG. 5.

Referring to FIGS. 1 and 6, operation 800 of the interaction between thedevices 100 and the web service of the web server 106 is shown. The webservice receives 802 the request message 105 requesting that the device100 begin communications with the web service. The web service uploads804 the required components 400, 402, 404, 406 (if any) of the componentapplication 302 to the device 100, in order to support subsequentinformation exchange between the web service and the device 100. Thedevice receives the transmitted component application 302 and proceedsto provision 806 the components 400, 402, 404, 406 by the runtimeenvironment, in order to configure the device as a web client of the webservice, by producing an executable version of the component application302. The user of the device 100 inputs 808 data into the user interface202 (see FIG. 2) of the device 100 for subsequent sending 810 to the webservice as a request message 105 for receiving web service operations.The web service processes the request message 105 and sends 812 theappropriate response message 105 including data for subsequent output onthe user interface 202. The device 100 receives 814 the message 105containing the data and the executable version of the componentapplication 302 outputs the data appropriately on the user interface202. Further data exchange 816 is performed between the device 100 andthe web service as per above, or the exchange is terminated 818 and theexecutable version of the component application 302 is either saved inthe memory 210 (see FIG. 2) or is deleted from the runtime environmentas desired.

Referring to FIGS. 1, 3 and 7, for example, operation 900 shows when thedevice 100 receives 902 the response message 105 containing messagedata, the appropriate workflow component 406 interprets 904 the datacontent of the message 105 according to the appropriate messagecomponent 404. The workflow component 406 then processes 906 the datacontent and inserts 910 the data into the corresponding data component400 for subsequent storage 912 in the memory module 210 (see FIG. 2).Further, if needed, the workflow component 406 also inserts 908 the datainto the appropriate presentation component 402 for subsequent display914 on the user interface 202 (see FIG. 2).

Referring to FIGS. 1, 3 and 8 operation 1000 shows data input 1002 foran action, such as pushing a button or selecting a menu item, which theuser performed 1003 on a user-interface element through the userinterface 202 (see FIG. 2). The relevant workflow component 406interprets 1004 the input data according to the appropriate presentationcomponent 404 and creates 1006 data entities which are defined by theappropriate data components 400. The workflow component 406 thenpopulates 1010 the data components 400 with the input data provided bythe user for subsequent storage 1012 in the memory module 210 (see FIG.2). Further, the workflow component 406 also inserts 1008 the input datainto the appropriate message component 404 for subsequent sending 1014of the input data as data entities to the web service in the message105, as defined by the message component 404.

It is recognized that component applications 302 which are created usingthe methods described above can require less time to create than hardcoded applications, since the component applications 302 do not use fullprogramming languages, but rather use standards-based technologies suchas XML and ECMAScript, which are comparatively simple and easy to learn.The methods can result in component applications 302 in which theuser-interface 202 and the definition of the data are decoupled. Thisdecoupling allows for modification of any component 400, 402, 404, 406in the component application 302 without affecting and requiringsubstantial changes to other components 400, 402, 404, 406 in theapplication 302, and thus can facilitate maintenance of the componentapplications 302, including modification and updating of the componentapplications 302 on the device 100.

FIG. 9 is a block diagram of a dual-mode mobile communication device710, which is a further example of the device 100 of FIGS. 1 and 6. Thedual-mode mobile communication device 710 includes a transceiver 711, amicroprocessor 738, a display 722, Flash memory 724, RAM memory 726,auxiliary input/output (I/O) devices 728, a serial port 730, a keyboard732, a speaker 734, a microphone 736, a short-range wirelesscommunications sub-system 740, and may also include other devicesub-systems 742. The transceiver 711 preferably includes transmit andreceive antennas 716, 718, a receiver 712, a transmitter 714, one ormore local oscillators 713, and a digital signal processor 720. Withinthe Flash memory 724, the dual-mode mobile communication device 710preferably includes a plurality of software modules 724A-724N that canbe executed by the microprocessor 738 (and/or the DSP 720), including avoice communication module 724A, a data communication module 724B, and aplurality of other operational modules 724N for carrying out a pluralityof other functions.

The dual-mode mobile communication device 710 is preferably a two-waycommunication device having voice and data communication capabilities.Thus, for example, the dual-mode mobile communication device 710 maycommunicate over a voice network, such as any of the analog or digitalcellular networks, and may also communicate over a data network. Thevoice and data networks are depicted in FIG. 9 by the communicationtower 719. These voice and data networks may be separate communicationnetworks using separate infrastructure, such as base stations, networkcontrollers, etc., or they may be integrated into a single wirelessnetwork.

The communication subsystem 711 is used to communicate with the voiceand data network 719, and includes the receiver 712, the transmitter714, the one or more local oscillators 713 and may also include the DSP720. The DSP 720 is used to send and receive signals to and from thetransmitter 714 and receiver 712, and is also utilized to receivecontrol information from the transmitter 714 and to provide controlinformation to the receiver 712. If the voice and data communicationsoccur at a single frequency, or closely-spaced set of frequencies, thena single local oscillator 713 may be used in conjunction with thetransmitter 714 and receiver 712. Alternatively, if differentfrequencies are utilized for voice communications versus datacommunications, then a plurality of local oscillators 713 can be used togenerate a plurality of frequencies corresponding to the voice and datanetworks 719. Although two antennas 716, 718 are depicted in FIG. 9, thedual-mode mobile communication device 710 could be used with a singleantenna structure. Information, which includes both voice and datainformation, is communicated to and from the communication module 711via a link between the DSP 720 and the microprocessor 738. The detaileddesign of the communication subsystem 711, such as frequency band,component selection, power level, etc., is dependent upon thecommunication network 719 in which the dual-mode mobile communicationdevice 710 is intended to operate. For example, a dual-mode mobilecommunication device 710 intended to operate in a North American marketmay include a communication subsystem 711 designed to operate with theMobitex™ or DataTAC™ mobile data communication networks and alsodesigned to operated with any of a variety of voice communicationnetworks, such as AMPS, TDMA, CDMA, PCS, etc., whereas a device 710intended for use in Europe may be configured to operate with the GeneralPacket Radio Service (GPRS) data communication network and the GSM voicecommunication network. Other types of data and voice networks, bothseparate and integrated, may also be utilized with the dual-mode mobilecommunication device 710.

Depending upon the type of network or networks 719, the accessrequirements for the dual-mode mobile communication device 710 may alsovary. For example, in the Mobitex and DataTAC data networks, mobiledevices are registered on the network using a unique identificationnumber associated with each device. In GPRS data networks, however,network access is associated with a subscriber or user of a mobiledevice. A GPRS device typically requires a subscriber identity module(“SIM”), which is required in order to operate a dual-mode mobilecommunication device on a GPRS network. Local or non-networkcommunication functions (if any) may be operable, without the SIM, but adual-mode mobile communication device will be unable to carry out anyfunctions involving communications over the data network 719, other thanany legally required operations, such as 911 emergency calling.

After any required network registration or activation procedures havebeen completed, the dual-mode mobile communication device 710 may thensend and receive communication signals, including both voice and datasignals, over the network 719 (or networks). Signals received by theantenna 716 from the communication network 719 are routed to thereceiver 712, which provides for signal amplification, frequency downconversion, filtering, channel selection, etc., and may also provideanalog to digital conversion. Analog to digital conversion of thereceived signal allows more complex communication functions, such asdigital demodulation and decoding to be performed using the DSP 720. Ina similar manner, signals to be transmitted to the network 719 areprocessed, including modulation and encoding, for example, by the DSP720 and are then provided to the transmitter 714 for digital to analogconversion, frequency up conversion, filtering, amplification andtransmission to the communication network 719 (or networks) via theantenna 718. Although a single transceiver 711 is shown in FIG. 9 forboth voice and data communications, it is possible that the dual-modemobile communication device 710 may include two distinct transceivers, afirst transceiver for transmitting and receiving voice signals, and asecond transceiver for transmitting and receiving data signals.

In addition to processing the communication signals, the DSP 720 alsoprovides for receiver and transmitter control. For example, the gainlevels applied to communication signals in the receiver 712 andtransmitter 714 may be adaptively controlled through automatic gaincontrol algorithms implemented in the DSP 720. Other transceiver controlalgorithms could also be implemented in the DSP 720 in order to providemore sophisticated control of the transceiver 711.

The microprocessor 738 preferably manages and controls the overalloperation of the dual-mode mobile communication device 710. Many typesof microprocessors or microcontrollers could be used here, or,alternatively, a single DSP 720 could be used to carry out the functionsof the microprocessor 738. Low-level communication functions, includingat least data and voice communications, are performed through the DSP720 in the transceiver 711. Other, high-level communicationapplications, such as a voice communication application 724A, and a datacommunication application 724B may be stored in the Flash memory 724 forexecution by the microprocessor 738. For example, the voicecommunication module 724A may provide a high-level user interfaceoperable to transmit and receive voice calls between the dual-modemobile communication device 710 and a plurality of other voice devicesvia the network 719. Similarly, the data communication module 724B mayprovide a high-level user interface operable for sending and receivingdata, such as e-mail messages, files, organizer information, short textmessages, etc., between the dual-mode mobile communication device 710and a plurality of other data devices via the network 719. In thedual-mode mobile communication device 710, a component framework 206 asdescribed above may also be implemented as a software module orapplication, or incorporated into one of the software modules 724A-724N.

The microprocessor 738 also interacts with other dual-mode mobilecommunication device subsystems, such as the display 722, Flash memory724, random access memory (RAM) 726, auxiliary input/output (I/O)subsystems 728, serial port 730, keyboard 732, speaker 734, microphone736, a short-range communications subsystem 740 and any other dual-modemobile communication device subsystems generally designated as 742.

Some of the subsystems shown in FIG. 9 perform communication-relatedfunctions, whereas other subsystems may provide resident or on-devicefunctions. Notably, some subsystems, such as keyboard 732 and display722 may be used for both communication-related functions, such asentering a text message for transmission over a data communicationnetwork, and device-resident functions such as a calculator or task listor other PDA type functions.

Operating system software used by the microprocessor 738 is preferablystored in a persistent store such as Flash memory 724. In addition tothe operating system, which controls all of the low-level functions ofthe dual-mode mobile communication device 710, the Flash memory 724 mayinclude a plurality of high-level software application programs, ormodules, such as a voice communication module 724A, a data communicationmodule 724B, an organizer module (not shown), or any other type ofsoftware module 724N. The Flash memory 724 also may include a filesystem for storing data. These modules are executed by themicroprocessor 738 and provide a high-level interface between a user ofthe dual-mode mobile communication device and the mobile device. Thisinterface typically includes a graphical component provided through thedisplay 722, and an input/output component provided through theauxiliary I/O 728, keyboard 732, speaker 734, and microphone 736. Theoperating system, specific dual-mode mobile communication devicesoftware applications or modules, or parts thereof, may be temporarilyloaded into a volatile store, such as RAM 726 for faster operation.Moreover, received communication signals may also be temporarily storedto RAM 726, before permanently writing them to a file system located inthe persistent store 724.

An exemplary application module 724N that may be loaded onto thedual-mode mobile communication device 710 is a personal informationmanager (PIM) application providing PDA functionality, such as calendarevents, appointments, and task items. This module 724N may also interactwith the voice communication module 724A for managing phone calls, voicemails, etc., and may also interact with the data communication modulefor managing e-mail communications and other data transmissions.Alternatively, all of the functionality of the voice communicationmodule 724A and the data communication module 724B may be integratedinto the PIM module.

The Flash memory 724 preferably provides a file system to facilitatestorage of PIM data items on the dual-mode mobile communication device710. The PIM application preferably includes the ability to send andreceive data items, either by itself, or in conjunction with the voiceand data communication modules 724A, 724B, via the wireless network 719.The PIM data items are preferably seamlessly integrated, synchronizedand updated, via the wireless network 719, with a corresponding set ofdata items stored or associated with a host computer system, therebycreating a mirrored system for data items associated with a particularuser.

The dual-mode mobile communication device 710 may also be manuallysynchronized with a host system by placing the dual-mode mobilecommunication device 710 in an interface cradle, which couples theserial port 730 of the dual-mode mobile communication device 710 to theserial port of the host system. The serial port 730 may also be used toenable a user to set preferences through an external device or softwareapplication, or to download other application modules 724N forinstallation. This wired download path may be used to load an encryptionkey onto the dual-mode mobile communication device 710, which is a moresecure method than exchanging encryption information via the wirelessnetwork 719.

Additional application modules 724N may be loaded onto the dual-modemobile communication device 710 through the network 719, through anauxiliary I/O subsystem 728, through the serial port 730, through theshort-range communications subsystem 740, or through any other suitablesubsystem 742, and installed by a user in the Flash memory 724 or RAM726. Such flexibility in application installation increases thefunctionality of the dual-mode mobile communication device 710 and mayprovide enhanced on-device functions, communication-related functions,or both. For example, secure communication applications may enableelectronic commerce functions and other such financial transactions tobe performed using the dual-mode mobile communication device 710.

When the dual-mode device 710 is operating in a data communication mode,a received signal, such as a text message or a web page download, willbe processed by the transceiver 711 and provided to the microprocessor738, which will preferably further process the received signal foroutput to the display 722, or, alternatively, to an auxiliary I/O device728. A user of the dual-mode mobile communication device 710 may alsocompose data items, such as email messages, using the keyboard 732,which is preferably a complete alphanumeric keyboard laid out in theQWERTY style, although other styles of complete alphanumeric keyboardssuch as the known DVORAK style may also be used. User input to thedual-mode mobile communication device 710 is further enhanced with aplurality of auxiliary I/O devices 728, which may include a thumbwheelinput device, a touchpad, a variety of switches, a rocker input switch,etc. The composed data items input by the user may then be transmittedover the communication network 719 via the transceiver 711.

When the dual-mode mobile communication device 710 is operating in avoice communication mode, the overall operation of the dual-mode mobilecommunication device 710 is substantially similar to the data mode,except that received signals are preferably be output to the speaker 734and voice signals for transmission are generated by a microphone 736.Alternative voice or audio I/O subsystems, such as a voice messagerecording subsystem, may also be implemented on the dual-mode mobilecommunication device 710. Although voice or audio signal output ispreferably accomplished primarily through the speaker 734, the display722 may also be used to provide an indication of the identity of acalling party, the duration of a voice call, or other voice call relatedinformation. For example, the microprocessor 738, in conjunction withthe voice communication module and the operating system software, maydetect the caller identification information of an incoming voice calland display it on the display 722.

A short-range communications subsystem 740 is also included in thedual-mode mobile communication device 710. For example, the short-rangecommunications subsystem 740 may include an infrared device andassociated circuits and components, or a short-range wirelesscommunication module such as a Bluetooth™ module or an 802.11 module toprovide for communication with similarly-enabled systems and devices.Those skilled in the art will appreciate that “Bluetooth” and 802.11refer to sets of specifications, available from the Institute ofElectrical and Electronics Engineers (IEEE), relating to wirelesspersonal area networks and wireless LANs, respectively.

Although the disclosure herein has been drawn to one or more exemplarysystems and methods, many variations will be apparent to thoseknowledgeable in the field, and such variations are within the scope ofthe application. For example, although XML and a subset of ECMAScriptare used in the examples provided, other languages and language variantsmay be used to define component applications 302.

1. A method of interacting with a web service by a wireless device overa wireless network, the method comprising: sending from the wirelessdevice a request network message to the web service to establishcommunication between the web service and the wireless device; receivingat the wireless device a component application in response to therequest network message, the component application program comprising aplurality of components: a first set of the components having metadatadescriptors expressed in a structured definition language having anumber of pre-defined elements representing specific attributes of aresource of the wireless device defining how a runtime environment ofthe wireless device configures the component application program; and asecond set of the components being expressed as a series of scriptedinstructions coupled to the metadata descriptors defining a workflow ofthe component application program the workflow comprising a workflowcomponent for defining an action to be performed when messages arrive atthe wireless device; the components being configured for provisioning bya runtime environment of the wireless device, the runtime environment toproduce an executable version of the component application programconfiguring the wireless device as a client of the web service; whereinthe execution of the executable version facilitates a subsequentexchange of data over the wireless network between the web service andthe wireless device.
 2. The method according to claim 1, wherein theruntime environment provides an interface for the executable version tothe functionality of a processor and an associated operating system ofan infrastructure of the wireless device and is provided by a componentframework providing a set of common services to component applications.3. The method according claim 2, wherein the executable version of thecomponent application executes in an application container, which is apart of component framework.
 4. The method according to claim 3, whereinthe runtime environment is configured for implementing capabilitiescomprising any of: provide communications for sending a network messageto the service, provide data input by a user of the device for supplyingdata content for a network message associated with the service, providedata presentation in response to a network message associated with theservice, provide data storage services for maintaining local client datain a memory of the device, and/or provide an execution environment for aprogramming language for coordinating operation of the components in theexecutable version.
 5. The method according to claim 2, furthercomprising dynamically generating the component descriptors for clientapplication messages and associated data from metadata defined for theservice.
 6. The method according to claim 5, further comprising a datacomponent in the first set of component definitions, the data-componentsfor describing a format of the data entities used by the program.
 7. Themethod according to claim 6, further comprising at least one messagecomponent in the first set of component definitions, each messagecomponent describing a format of the messages used by the program tocommunicate over the network with the service.
 8. The method accordingto claim 7, further comprising a presentation component in the first setof components, the presentation components for defining the appearanceand behavior of the component application program as presented on a userinterface of the device.
 9. The method according to claim 1, wherein theworkflow component in the second set of components defines processingthat occurs when an action is to be performed as specified by one of thefirst set of components.
 10. The method according to claim 2, furthercomprising executing the executable version by the metadata basedexecution model, the model configured for keeping the metadatadefinitions in the structured definition language for parsing duringexecution.
 11. The method according to claim 2, further comprisingexecuting the executable version by the metadata based execution model,the model configured for using a native representation of structureddefinition language nodes during execution.
 12. The method according toclaim 11, further comprising sending a network message initiated byinteraction of a user of the device with a user interface element, thenetwork message comprising data entities created by the workflowcomponent corresponding to the user interface element.
 13. The methodaccording to claim 12, further comprising specifying a client type ofthe device in the network message for providing the presentationcomponent as platform specific for a predefined runtime environment. 14.The method according to claim 13, wherein the network message isconfigured according to the message component for comprising the dataentities based on the structured definition language.
 15. The methodaccording to claim 12, further comprising receiving a response networkmessage comprising message data related to the data entities, theresponse network message configured for subsequent presentation of themessage data on a user interface of the device, wherein the message datais formatted based on the structured definition language.
 16. The methodaccording to claim 2, wherein the set of common services include one ormore of: a communication service; a presentation service; a persistenceservice; an access service; a provisioning service; and an utilityservice.
 17. The method according to claim 8, wherein each messagecomponent uniquely maps to a message described by a schema-definition ofthe service.
 18. The method according to claim 7, wherein the workflowcomponent supports a correlation between messages.
 19. The methodaccording to claim 2, wherein the workflow component defines applicationflow through a set of rules for operations on the first set ofcomponents.
 20. A wireless device configured for interacting over awireless network with a web service using an executable version of acomponent application program comprising a plurality of components, thewireless device comprising; a device infrastructure for operating thewireless device comprising a processor and an associated memory forexecuting the executable version; a user interface coupled to the deviceinfrastructure having an input device and an output device configuredfor communication with the executable version; a network connectioninterface coupled to the device infrastructure and configured forcommunicating with the network; and a runtime environment for processingthe component application program to generate the executable version forconfiguring the device as a client of the web service, the runtimeenvironment configured for processing a first set of the componentshaving metadata descriptors expressed in a structured definitionlanguage having a number of pre-defined elements representing specificattributes of a resource of the wireless device for definingconfiguration information of the component application program and asecond set of the components being expressed as a series of scriptedinstructions coupled to the metadata descriptors for defining a workflowof the component application program, the workflow component defining anaction to be performed when messages arrive at the wireless device;wherein the execution of the executable version facilitates a subsequentexchange of data over the wireless network between the web service andthe wireless device.